HTML5's Q element

[Yahia Chlyeh]

Having quotation punctuation generated by the user agent is utterly wrong. This discussion has been going from a long time ago in the mailing lists. Quotation marks for the /q/ element should be provided in the source so that 1) non-graphical user agents can represent them, otherwise the content would be flawed, and 2) to avoid issues that arise when writing content in different languages: in French for example, the reference of the quote is written inside the quote inside quotation marks (..., he whispered, ...) while in English that's put outside the quotation marks; there's also problems with punctuation in/outside quotation marks that's different in languages.
After all these arguments, the best is to prevent automatic generation of quotation marks and notify web authors to add them outside the /q/ element itself, since if quotes generation is preserved, then why not auto generate periods for end of /p/ elements too?
--
Yahia Chlyeh

[Ian Hickson]

On Wed, 26 Aug 2009, Yahia Chlyeh wrote:
>
> Having quotation punctuation generated by the user agent is utterly
> wrong. This discussion has been going from a long time ago in the
> mailing lists. Quotation marks for the /q/ element should be provided in
> the source so that 1) non-graphical user agents can represent them,
> otherwise the content would be flawed,

Why can't non-graphical user agents insert quotes also?


> and 2) to avoid issues that arise when writing content in different
> languages: in French for example, the reference of the quote is written
> inside the quote inside quotation marks (..., he whispered, ...) while
> in English that's put outside the quotation marks;

Indeed.


> there's also problems with punctuation in/outside quotation marks that's
> different in languages.

Indeed.


> After all these arguments, the best is to prevent automatic generation
> of quotation marks and notify web authors to add them outside the /q/
> element itself, since if quotes generation is preserved, then why not
> auto generate periods for end of /p/ elements too?

IE8, Firefox, Safari, and Opera all render quotes. We lost this war.

You don't have to use <q> though.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[ownedthx]

For IE8, FF 3.5, and Opera 10 (although not Safari 4), this behavior of adding quotes is done with the default CSS style sheet of the browser; not in the HTML rendering itself.

If you style q like so:

q:before {
  content: no-open-quote;
}

q:after {
  content: no-close-quote;
}

Then the quotes go away in those 3 browsers.

I'd hope the specification could be amended based on Yahia's excellent points.


Seth

On Tue, Sep 1, 2009 at 7:23 PM, Ian Hickson <ian@...> wrote:

On Wed, 26 Aug 2009, Yahia Chlyeh wrote:
>
> Having quotation punctuation generated by the user agent is utterly
> wrong. This discussion has been going from a long time ago in the
> mailing lists. Quotation marks for the /q/ element should be provided in
> the source so that 1) non-graphical user agents can represent them,
> otherwise the content would be flawed,

Why can't non-graphical user agents insert quotes also?

> and 2) to avoid issues that arise when writing content in different
> languages: in French for example, the reference of the quote is written
> inside the quote inside quotation marks (..., he whispered, ...) while
> in English that's put outside the quotation marks;

Indeed.

> there's also problems with punctuation in/outside quotation marks that's
> different in languages.

Indeed.

> After all these arguments, the best is to prevent automatic generation
> of quotation marks and notify web authors to add them outside the /q/
> element itself, since if quotes generation is preserved, then why not
> auto generate periods for end of /p/ elements too?

IE8, Firefox, Safari, and Opera all render quotes. We lost this war.

You don't have to use <q> though.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[T.J. Crowder]

> I'd hope the specification could be amended based on Yahia's excellent points.

+1 to that.  Having the UA add the quotes is not a good idea, and will
almost certainly lead to hacks like UAs looking to see if the quotes
are already there and only adding them if they're not.

Even if IE8, FF3.5, et. al. and such are already doing this, they're
implementing the bleeding edge of this spec and should be agile enough
to cope with changes to it as it is finalised.
--
T.J. Crowder


2009/9/2 Seth Call <sethcall@...>

>
> For IE8, FF 3.5, and Opera 10 (although not Safari 4), this behavior of adding quotes is done with the default CSS style sheet of the browser; not in the HTML rendering itself.
>
> If you style q like so:
>
>> q:before {
>>   content: no-open-quote;
>> }
>>
>> q:after {
>>   content: no-close-quote;
>> }
>
>
> Then the quotes go away in those 3 browsers.
>
> I'd hope the specification could be amended based on Yahia's excellent points.
>
>
> Seth
>
> On Tue, Sep 1, 2009 at 7:23 PM, Ian Hickson <ian@...> wrote:
>>
>> On Wed, 26 Aug 2009, Yahia Chlyeh wrote:
>> >
>> > Having quotation punctuation generated by the user agent is utterly
>> > wrong. This discussion has been going from a long time ago in the
>> > mailing lists. Quotation marks for the /q/ element should be provided in
>> > the source so that 1) non-graphical user agents can represent them,
>> > otherwise the content would be flawed,
>>
>> Why can't non-graphical user agents insert quotes also?
>>
>>
>> > and 2) to avoid issues that arise when writing content in different
>> > languages: in French for example, the reference of the quote is written
>> > inside the quote inside quotation marks (..., he whispered, ...) while
>> > in English that's put outside the quotation marks;
>>
>> Indeed.
>>
>>
>> > there's also problems with punctuation in/outside quotation marks that's
>> > different in languages.
>>
>> Indeed.
>>
>>
>> > After all these arguments, the best is to prevent automatic generation
>> > of quotation marks and notify web authors to add them outside the /q/
>> > element itself, since if quotes generation is preserved, then why not
>> > auto generate periods for end of /p/ elements too?
>>
>> IE8, Firefox, Safari, and Opera all render quotes. We lost this war.
>>
>> You don't have to use <q> though.
>>
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>
>

[Ryan Roberts-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I'm also in support of Yahia's points, the UA shouldn't add quotes in. Whether it's no common or not it's a bad idea that needs changing sooner rather than later.

Ryan


T.J. Crowder wrote:

I'd hope the specification could be amended based on Yahia's excellent points.
    

+1 to that.  Having the UA add the quotes is not a good idea, and will
almost certainly lead to hacks like UAs looking to see if the quotes
are already there and only adding them if they're not.

Even if IE8, FF3.5, et. al. and such are already doing this, they're
implementing the bleeding edge of this spec and should be agile enough
to cope with changes to it as it is finalised.
--
T.J. Crowder


2009/9/2 Seth Call sethcall@...
  

For IE8, FF 3.5, and Opera 10 (although not Safari 4), this behavior of adding quotes is done with the default CSS style sheet of the browser; not in the HTML rendering itself.

If you style q like so:

    

q:before {
  content: no-open-quote;
}

q:after {
  content: no-close-quote;
}
      

Then the quotes go away in those 3 browsers.

I'd hope the specification could be amended based on Yahia's excellent points.


Seth

On Tue, Sep 1, 2009 at 7:23 PM, Ian Hickson ian@... wrote:
    

On Wed, 26 Aug 2009, Yahia Chlyeh wrote:
      

Having quotation punctuation generated by the user agent is utterly
wrong. This discussion has been going from a long time ago in the
mailing lists. Quotation marks for the /q/ element should be provided in
the source so that 1) non-graphical user agents can represent them,
otherwise the content would be flawed,
        

Why can't non-graphical user agents insert quotes also?


      

and 2) to avoid issues that arise when writing content in different
languages: in French for example, the reference of the quote is written
inside the quote inside quotation marks (..., he whispered, ...) while
in English that's put outside the quotation marks;
        

Indeed.


      

there's also problems with punctuation in/outside quotation marks that's
different in languages.
        

Indeed.


      

After all these arguments, the best is to prevent automatic generation
of quotation marks and notify web authors to add them outside the /q/
element itself, since if quotes generation is preserved, then why not
auto generate periods for end of /p/ elements too?
        

IE8, Firefox, Safari, and Opera all render quotes. We lost this war.

You don't have to use <q> though.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

      

[Arthur Clifford]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I think this comes down to how HTML/HTML5 is going to be utilized, is it
describing a document object model; in which case a quote (or quoted text)
is an object and proper display of a quote object should be up to the user
agent, as informed by style sheets, thus keeping content and its face
separate. Or is HTML merely a markup language, in which case what is the
philosophical reason for having a q-tag? When is it used and why?

Back when there were proof-readers they would mark-up something that should
be a quote; isn't that what you're doing in html too? Quoted content needs
to be distinguishable from the content around it, which is done with
quotation-marks. Shouldn't the marks used in a document for quoted content
be identifiable through styles and/or along with a section of quoted text?
If so, isn't the quote tag the logical place to define those styles, either
in a global style or as a style attribute on the quote tag?

The localization argument I thought was a compelling argument for the user
agent to handle putting in quotes. It is an example of what is possible when
you treat a document as a DOM versus just marking up text. If quoted content
is treated like an object then things like localization are easier to
facilitate.

I would hope that content-editors such as DreamWeaver would help out by
indicating usage of " and q together and would somehow notify the user if
that is what they want to do. The specification should recommend against an
html renderer doing such checks though. I think people would figure out
quickly that things are double-quoted and fixing that shouldn't be hard.

[Henri Sivonen]

On Sep 2, 2009, at 16:56, Ryan Roberts wrote:

> I'm also in support of Yahia's points, the UA shouldn't add quotes  
> in. Whether it's no common or not it's a bad idea that needs  
> changing sooner rather than later.


It's a bad idea, sure. But it doesn't follow that <q> in itself is a  
good idea and needs changing.

My conclusion is that adding quotes is a bad idea *and* <q> in itself  
isn't particularly useful. Thus, the solution is not to use <q> in  
newly-authored documents.

Hixie, maybe <q> should be obsolete but conforming...

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

[Ian Hickson]

On Wed, 2 Sep 2009, Seth Call wrote:

>
> For IE8, FF 3.5, and Opera 10 (although not Safari 4), this behavior of
> adding quotes is done with the default CSS style sheet of the browser;
> not in the HTML rendering itself.
>
> If you style q like so:
>
> q:before {
> >   content: no-open-quote;
> > }
> >
> > q:after {
> >   content: no-close-quote;
> > }
> >
>
>
> Then the quotes go away in those 3 browsers.

On Wed, 2 Sep 2009, T.J. Crowder wrote:
>
> Having the UA add the quotes is not a good idea, and will almost
> certainly lead to hacks like UAs looking to see if the quotes are
> already there and only adding them if they're not.
>
> Even if IE8, FF3.5, et. al. and such are already doing this, they're
> implementing the bleeding edge of this spec and should be agile enough
> to cope with changes to it as it is finalised.

On Wed, 2 Sep 2009, Ryan Roberts wrote:
>
> Whether it's no common or not it's a bad idea that needs changing sooner
> rather than later.

On Thu, 3 Sep 2009, Henri Sivonen wrote:
>
> It's a bad idea, sure. But it doesn't follow that <q> in itself is a
> good idea and needs changing.
>
> My conclusion is that adding quotes is a bad idea *and* <q> in itself
> isn't particularly useful. Thus, the solution is not to use <q> in
> newly-authored documents.
>
> Hixie, maybe <q> should be obsolete but conforming...

On Thu, 3 Sep 2009, Arthur Clifford wrote:

>
> I think this comes down to how HTML/HTML5 is going to be utilized, is it
> describing a document object model; in which case a quote (or quoted
> text) is an object and proper display of a quote object should be up to
> the user agent, as informed by style sheets, thus keeping content and
> its face separate. Or is HTML merely a markup language, in which case
> what is the philosophical reason for having a q-tag? When is it used and
> why?
>
> Back when there were proof-readers they would mark-up something that
> should be a quote; isn't that what you're doing in html too? Quoted
> content needs to be distinguishable from the content around it, which is
> done with quotation-marks. Shouldn't the marks used in a document for
> quoted content be identifiable through styles and/or along with a
> section of quoted text? If so, isn't the quote tag the logical place to
> define those styles, either in a global style or as a style attribute on
> the quote tag?
>
> The localization argument I thought was a compelling argument for the
> user agent to handle putting in quotes. It is an example of what is
> possible when you treat a document as a DOM versus just marking up text.
> If quoted content is treated like an object then things like
> localization are easier to facilitate.
>
> I would hope that content-editors such as DreamWeaver would help out by
> indicating usage of " and q together and would somehow notify the user
> if that is what they want to do. The specification should recommend
> against an html renderer doing such checks though. I think people would
> figure out quickly that things are double-quoted and fixing that
> shouldn't be hard.

If you want quote marks in the source, use quote marks in the source, and
don't use <q>.

If you want quote marks added automatically, use <q>.

It would be stupid of us to try to change this now given that all four
major browsers ship with a <q> that inserts quote marks. This was
discussed in depth last year, and the spec was changed (from not inserting
quotes to inserting quotes) after it was concluded that swimming against
the browser vendors here was futile.

At this point, the <q> element's purpose is to enable CSS-based quotation
mark injection. If you don't want that, then don't use <q>.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[T.J. Crowder]

2009/9/4 Ian Hickson <ian@...>

>
> On Wed, 2 Sep 2009, Seth Call wrote:
> >
> > For IE8, FF 3.5, and Opera 10 (although not Safari 4), this behavior of
> > adding quotes is done with the default CSS style sheet of the browser;
> > not in the HTML rendering itself.
> >
> > If you style q like so:
> >
> > q:before {
> > >   content: no-open-quote;
> > > }
> > >
> > > q:after {
> > >   content: no-close-quote;
> > > }
> > >
> >
> >
> > Then the quotes go away in those 3 browsers.
>
> On Wed, 2 Sep 2009, T.J. Crowder wrote:
> >
> > Having the UA add the quotes is not a good idea, and will almost
> > certainly lead to hacks like UAs looking to see if the quotes are
> > already there and only adding them if they're not.
> >
> > Even if IE8, FF3.5, et. al. and such are already doing this, they're
> > implementing the bleeding edge of this spec and should be agile enough
> > to cope with changes to it as it is finalised.
>
> On Wed, 2 Sep 2009, Ryan Roberts wrote:
> >
> > Whether it's no common or not it's a bad idea that needs changing sooner
> > rather than later.
>
> On Thu, 3 Sep 2009, Henri Sivonen wrote:
> >
> > It's a bad idea, sure. But it doesn't follow that <q> in itself is a
> > good idea and needs changing.
> >
> > My conclusion is that adding quotes is a bad idea *and* <q> in itself
> > isn't particularly useful. Thus, the solution is not to use <q> in
> > newly-authored documents.
> >
> > Hixie, maybe <q> should be obsolete but conforming...
>
> On Thu, 3 Sep 2009, Arthur Clifford wrote:
> >
> > I think this comes down to how HTML/HTML5 is going to be utilized, is it
> > describing a document object model; in which case a quote (or quoted
> > text) is an object and proper display of a quote object should be up to
> > the user agent, as informed by style sheets, thus keeping content and
> > its face separate. Or is HTML merely a markup language, in which case
> > what is the philosophical reason for having a q-tag? When is it used and
> > why?
> >
> > Back when there were proof-readers they would mark-up something that
> > should be a quote; isn't that what you're doing in html too? Quoted
> > content needs to be distinguishable from the content around it, which is
> > done with quotation-marks. Shouldn't the marks used in a document for
> > quoted content be identifiable through styles and/or along with a
> > section of quoted text? If so, isn't the quote tag the logical place to
> > define those styles, either in a global style or as a style attribute on
> > the quote tag?
> >
> > The localization argument I thought was a compelling argument for the
> > user agent to handle putting in quotes. It is an example of what is
> > possible when you treat a document as a DOM versus just marking up text.
> > If quoted content is treated like an object then things like
> > localization are easier to facilitate.
> >
> > I would hope that content-editors such as DreamWeaver would help out by
> > indicating usage of " and q together and would somehow notify the user
> > if that is what they want to do. The specification should recommend
> > against an html renderer doing such checks though. I think people would
> > figure out quickly that things are double-quoted and fixing that
> > shouldn't be hard.
>
> If you want quote marks in the source, use quote marks in the source, and
> don't use <q>.
>
> If you want quote marks added automatically, use <q>.
>
> It would be stupid of us to try to change this now given that all four
> major browsers ship with a <q> that inserts quote marks

Strongly disagree.  The spec is *not final* yet.  If vendors implement
in-progress specs, they must expect them to change.  Fix it now and
within a year, it's done, implementations and content will be updated
to match.  To fail to correct this now just sets up ongoing,
unnecessary silliness for years to come.

> This was
> discussed in depth last year, and the spec was changed (from not inserting
> quotes to inserting quotes) after it was concluded that swimming against
> the browser vendors here was futile.
>
> At this point, the <q> element's purpose is to enable CSS-based quotation
> mark injection. If you don't want that, then don't use <q>.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

--
T.J. Crowder
tj / crowder software / com
www.crowdersoftware.com

[Ryan Roberts-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Ian Hickson wrote:

On Wed, 2 Sep 2009, Seth Call wrote:
  

For IE8, FF 3.5, and Opera 10 (although not Safari 4), this behavior of 
adding quotes is done with the default CSS style sheet of the browser; 
not in the HTML rendering itself.

If you style q like so:

q:before {
    

  content: no-open-quote;
}

q:after {
  content: no-close-quote;
}

      

Then the quotes go away in those 3 browsers.
    

On Wed, 2 Sep 2009, T.J. Crowder wrote:
  

Having the UA add the quotes is not a good idea, and will almost 
certainly lead to hacks like UAs looking to see if the quotes are 
already there and only adding them if they're not.

Even if IE8, FF3.5, et. al. and such are already doing this, they're 
implementing the bleeding edge of this spec and should be agile enough 
to cope with changes to it as it is finalised.
    

On Wed, 2 Sep 2009, Ryan Roberts wrote:
  

Whether it's no common or not it's a bad idea that needs changing sooner 
rather than later.
    

On Thu, 3 Sep 2009, Henri Sivonen wrote:
  

It's a bad idea, sure. But it doesn't follow that <q> in itself is a 
good idea and needs changing.

My conclusion is that adding quotes is a bad idea *and* <q> in itself 
isn't particularly useful. Thus, the solution is not to use <q> in 
newly-authored documents.

Hixie, maybe <q> should be obsolete but conforming...
    

On Thu, 3 Sep 2009, Arthur Clifford wrote:
  

I think this comes down to how HTML/HTML5 is going to be utilized, is it 
describing a document object model; in which case a quote (or quoted 
text) is an object and proper display of a quote object should be up to 
the user agent, as informed by style sheets, thus keeping content and 
its face separate. Or is HTML merely a markup language, in which case 
what is the philosophical reason for having a q-tag? When is it used and 
why?

Back when there were proof-readers they would mark-up something that 
should be a quote; isn't that what you're doing in html too? Quoted 
content needs to be distinguishable from the content around it, which is 
done with quotation-marks. Shouldn't the marks used in a document for 
quoted content be identifiable through styles and/or along with a 
section of quoted text? If so, isn't the quote tag the logical place to 
define those styles, either in a global style or as a style attribute on 
the quote tag?

The localization argument I thought was a compelling argument for the 
user agent to handle putting in quotes. It is an example of what is 
possible when you treat a document as a DOM versus just marking up text. 
If quoted content is treated like an object then things like 
localization are easier to facilitate.

I would hope that content-editors such as DreamWeaver would help out by 
indicating usage of " and q together and would somehow notify the user 
if that is what they want to do. The specification should recommend 
against an html renderer doing such checks though. I think people would 
figure out quickly that things are double-quoted and fixing that 
shouldn't be hard.
    

If you want quote marks in the source, use quote marks in the source, and 
don't use <q>.

If you want quote marks added automatically, use <q>.
  

This makes little sense. What you're saying is <q> has no semantic purpose anymore, it's there for presentation (see your further down).

What is the point in moving things forward if we can't correct past mistakes?

It would be stupid of us to try to change this now given that all four 
major browsers ship with a <q> that inserts quote marks. This was 
discussed in depth last year, and the spec was changed (from not inserting 
quotes to inserting quotes) after it was concluded that swimming against 
the browser vendors here was futile.
  

Then hand the spec over to them.

At this point, the <q> element's purpose is to enable CSS-based quotation 
mark injection. If you don't want that, then don't use <q>.
  

So at this point how do you mark up an inline quote?

Ryan

[Ian Hickson]

On Fri, 4 Sep 2009, T.J. Crowder wrote:
> >
> > It would be stupid of us to try to change this now given that all four
> > major browsers ship with a <q> that inserts quote marks
>
> Strongly disagree.  The spec is *not final* yet.

HTML4, which required quotes in the exact same manner, has been "final"
for over ten years now.


> If vendors implement in-progress specs, they must expect them to change.  
> Fix it now and within a year, it's done, implementations and content
> will be updated to match.

HTML5 said to _not_ render quotes for at least 2 years, during which time
the only change from browser vendors was for Microsoft to change from not
including quotes (as per HTML5 at the time) to including quotes (as per
HTML4). So evidence seems to contradict your statement.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Ian Hickson]

On Fri, 4 Sep 2009, Ryan Roberts wrote:
> >
> > If you want quote marks in the source, use quote marks in the source,
> > and don't use<q>.
> >
> > If you want quote marks added automatically, use<q>.
>
> This makes little sense. What you're saying is <q> has no semantic
> purpose anymore, it's there for presentation (see your further down).

I'm not sure what you mean by "semantic purpose". In what sense is all of
HTML not just "there for presentation"?

The whole point of HTML is to be a media-independent, platform-
independent, stylable documenta and application language. Presentation (on
multiple media, devices, etc) is the most important use case.


> > It would be stupid of us to try to change this now given that all four
> > major browsers ship with a<q> that inserts quote marks. This was
> > discussed in depth last year, and the spec was changed (from not
> > inserting quotes to inserting quotes) after it was concluded that
> > swimming against the browser vendors here was futile.
>    
> Then hand the spec over to them.

In what sense have we not handed the spec over to them? Browser vendors,
as the most high-profile implementors of the spec, have full control over
what ends up being implemented. I'm not going to make the spec say
somethin they won't do; that would just turn the spec into an especially
dry form of science fiction.


> > At this point, the<q> element's purpose is to enable CSS-based
> > quotation mark injection. If you don't want that, then don't use<q>.
>
> So at this point how do you mark up an inline quote?

One of the following:

   <p>Ryan asked "So at this point how do you mark up an inline
   quote?"</p>

   <p>Ryan asked <q>So at this point how do you mark up an inline
   quote?</q></p>

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Ryan Roberts-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Ian Hickson wrote:

On Fri, 4 Sep 2009, Ryan Roberts wrote:
  

If you want quote marks in the source, use quote marks in the source, 
and don't use<q>.

If you want quote marks added automatically, use<q>.
      

This makes little sense. What you're saying is <q> has no semantic 
purpose anymore, it's there for presentation (see your further down).
    

I'm not sure what you mean by "semantic purpose". In what sense is all of 
HTML not just "there for presentation"?

The whole point of HTML is to be a media-independent, platform- 
independent, stylable documenta and application language. Presentation (on 
multiple media, devices, etc) is the most important use case.

  

Maybe I'm not explaining myself properly, I'm just a web designer and nobody fancy. I believed many if not most elements such as <q>, were there to describe the content. I see now this isn't the case with <q>, but it's only really like that because it's broken and nobody wants to fix it.

It would be stupid of us to try to change this now given that all four 
major browsers ship with a<q> that inserts quote marks. This was 
discussed in depth last year, and the spec was changed (from not 
inserting quotes to inserting quotes) after it was concluded that 
swimming against the browser vendors here was futile.
      

   
Then hand the spec over to them.
    

In what sense have we not handed the spec over to them? Browser vendors, 
as the most high-profile implementors of the spec, have full control over 
what ends up being implemented. I'm not going to make the spec say 
somethin they won't do; that would just turn the spec into an especially 
dry form of science fiction.

  

I understand that they have final say over what goes in their browsers, but I can't say I like them having final say over the HTML5 spec itself.

At this point, the<q> element's purpose is to enable CSS-based 
quotation mark injection. If you don't want that, then don't use<q>.
      

So at this point how do you mark up an inline quote?
    

One of the following:

   <p>Ryan asked "So at this point how do you mark up an inline 
   quote?"</p>

   <p>Ryan asked <q>So at this point how do you mark up an inline 
   quote?</q></p>

  

In that case why not have <p> auto inert a period then we could have the following:

Ryan doesn't like what he's hearing.

<p>Ryan doesn't like what he's hearing</p>

Ryan

[Ian Hickson]

On Fri, 4 Sep 2009, Ryan Roberts wrote:

> Ian Hickson wrote:
> > On Fri, 4 Sep 2009, Ryan Roberts wrote:
> > > >
> > > > If you want quote marks in the source, use quote marks in the
> > > > source, and don't use<q>.
> > > >
> > > > If you want quote marks added automatically, use<q>.
> > >
> > > This makes little sense. What you're saying is<q> has no semantic
> > > purpose anymore, it's there for presentation (see your further
> > > down).
> >
> > I'm not sure what you mean by "semantic purpose". In what sense is all
> > of HTML not just "there for presentation"?
> >
> > The whole point of HTML is to be a media-independent, platform-
> > independent, stylable documenta and application language. Presentation
> > (on multiple media, devices, etc) is the most important use case.
>
> Maybe I'm not explaining myself properly, I'm just a web designer and
> nobody fancy. I believed many if not most elements such as <q>, were
> there to describe the content. I see now this isn't the case with <q>,
> but it's only really like that because it's broken and nobody wants to
> fix it.

<q> does describe contents -- it means "this is a quote, so add quote
marks". Just like <p> means "this is a paragraph, so add a line break
before and after". Or in different media, "This is a quote, so use a
slightly different voice" and "This is a paragraph, so pause before and
after". Elements in HTML are media-independent presentation hooks.

> > > > It would be stupid of us to try to change this now given that all
> > > > four major browsers ship with a<q> that inserts quote marks. This
> > > > was discussed in depth last year, and the spec was changed (from
> > > > not inserting quotes to inserting quotes) after it was concluded
> > > > that swimming against the browser vendors here was futile.
> > >
> > > Then hand the spec over to them.
> >
> > In what sense have we not handed the spec over to them? Browser
> > vendors, as the most high-profile implementors of the spec, have full
> > control over what ends up being implemented. I'm not going to make the
> > spec say somethin they won't do; that would just turn the spec into an
> > especially dry form of science fiction.
>
> I understand that they have final say over what goes in their browsers,
> but I can't say I like them having final say over the HTML5 spec itself.

What's the point in the HTML5 spec describing something that isn't what
the browsers do?

> > > > At this point, the<q> element's purpose is to enable CSS-based
> > > > quotation mark injection. If you don't want that, then don't
> > > > use<q>.
> > >
> > > So at this point how do you mark up an inline quote?
> >
> > One of the following:
> >
> >     <p>Ryan asked "So at this point how do you mark up an inline
> >     quote?"</p>
> >
> >     <p>Ryan asked<q>So at this point how do you mark up an inline
> >     quote?</q></p>
>
> In that case why not have <p> auto inert a period then we could have the
> following:
>
> Ryan doesn't like what he's hearing.
>
> <p>Ryan doesn't like what he's hearing</p>

We do -- well, not periods, but line breaks. <p> inserts line breaks,
which you can override from the CSS, just like <q> inserts quotes, which
you can override from the CSS.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[T.J. Crowder]

2009/9/4 Ian Hickson <ian@...>:
> On Fri, 4 Sep 2009, T.J. Crowder wrote:
>> >
>> > It would be stupid of us to try to change this now given that all four
>> > major browsers ship with a <q> that inserts quote marks
>>
>> Strongly disagree.  The spec is *not final* yet.
>
> HTML4, which required quotes in the exact same manner, has been "final"
> for over ten years now.

Apologies, I thought <q> was one of the several new tags.  If the <q>
was defined in HTML4 with the UAs rendering quotes (which -- with
apologies -- I just checked and it is), then that definition -- wrong
though it surely was and is -- should be left alone.  The idea that
UAs should render quotes in HTML4 but not in HTML5 is even more
nonsensical than the HTML4 spec saying they should render quotes in
the first place.  Not only has the ship sailed, it's come back and
gone out again dozens of time, been decommissioned, and sold for
scrap.

>
>
>> If vendors implement in-progress specs, they must expect them to change.
>> Fix it now and within a year, it's done, implementations and content
>> will be updated to match.
>
> HTML5 said to _not_ render quotes for at least 2 years, during which time
> the only change from browser vendors was for Microsoft to change from not
> including quotes (as per HTML5 at the time) to including quotes (as per
> HTML4). So evidence seems to contradict your statement.

That statement was based on my mistaken belief that <q> was new, and
on that basis I would stand by it.  But my basis was incorrect.

>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
--
T.J. Crowder
tj / crowder software / com
www.crowdersoftware.com

[Ryan Roberts-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Ian Hickson wrote:

On Fri, 4 Sep 2009, Ryan Roberts wrote:
  

Ian Hickson wrote:
    

On Fri, 4 Sep 2009, Ryan Roberts wrote:
      

If you want quote marks in the source, use quote marks in the 
source, and don't use<q>.

If you want quote marks added automatically, use<q>.
          

This makes little sense. What you're saying is<q> has no semantic 
purpose anymore, it's there for presentation (see your further 
down).
        

I'm not sure what you mean by "semantic purpose". In what sense is all 
of HTML not just "there for presentation"?

The whole point of HTML is to be a media-independent, platform- 
independent, stylable documenta and application language. Presentation 
(on multiple media, devices, etc) is the most important use case.
      

Maybe I'm not explaining myself properly, I'm just a web designer and 
nobody fancy. I believed many if not most elements such as <q>, were 
there to describe the content. I see now this isn't the case with <q>, 
but it's only really like that because it's broken and nobody wants to 
fix it.
    

<q> does describe contents -- it means "this is a quote, so add quote 
marks". Just like <p> means "this is a paragraph, so add a line break 
before and after". Or in different media, "This is a quote, so use a 
slightly different voice" and "This is a paragraph, so pause before and 
after". Elements in HTML are media-independent presentation hooks.


  

Right, HTML is tied much closer to the browser than I thought it was. Even if that doesn't make sense to you thanks for the feedback, I think I'm understanding it better.

It would be stupid of us to try to change this now given that all 
four major browsers ship with a<q> that inserts quote marks. This 
was discussed in depth last year, and the spec was changed (from 
not inserting quotes to inserting quotes) after it was concluded 
that swimming against the browser vendors here was futile.
          

Then hand the spec over to them.
        

In what sense have we not handed the spec over to them? Browser 
vendors, as the most high-profile implementors of the spec, have full 
control over what ends up being implemented. I'm not going to make the 
spec say somethin they won't do; that would just turn the spec into an 
especially dry form of science fiction.
      

I understand that they have final say over what goes in their browsers, 
but I can't say I like them having final say over the HTML5 spec itself.
    

What's the point in the HTML5 spec describing something that isn't what 
the browsers do?

  

To create a standard they all aim for... no clearly this isn't the case.

At this point, the<q> element's purpose is to enable CSS-based 
quotation mark injection. If you don't want that, then don't 
use<q>.
          

So at this point how do you mark up an inline quote?
        

One of the following:

    <p>Ryan asked "So at this point how do you mark up an inline
    quote?"</p>

    <p>Ryan asked<q>So at this point how do you mark up an inline
    quote?</q></p>
      

In that case why not have <p> auto inert a period then we could have the 
following:

Ryan doesn't like what he's hearing.

<p>Ryan doesn't like what he's hearing</p>
    

We do -- well, not periods, but line breaks. <p> inserts line breaks, 
which you can override from the CSS, just like <q> inserts quotes, which 
you can override from the CSS.

  

[Arthur Clifford]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Ryan and TJ,

 

I think you have things backward.

 

In HTML tags are what identify the structure/content/semantics of a document. Quotation marks (“) have no semantic value at all. The q tag on the other hand identifies a section of text as being a quote. Since q tags identify something as a quote, as an object within the document, it makes more sense to affiliate the symbols to surround the quoted text during display with the objects themselves; meaning it makes more sense to have the q tag dictate quote marks. As a programmer I will tell you that if I wanted to identify quoted material I’d much rather parse a well-formed html document for a q and /q  tag than “ marks. Besides “ is not a quote mark in printing, there are open and closed quote marks.

 

I understand the frustration regarding the argument that because the browser vendors do it that’s the way it is going to be. I also understand Ian’s perspective, but I would say the browser vendors went the way they did because it makes more sense from a development perspective and ultimately a user experience to do things that way. The syntax of any programming language first and foremost is designed to make parsing it for use by the software into a data structure. If you think of html as informing an object model, then your opinion about quotes and q-tags becomes more and more invalid. The current implementation of q is far more flexible for the greatest number of outputs and use-cases.

 

Ian missed a method of styling quotes the way you want:

 

<p>blah blah blah, “<span style=”RyanQuotes”>some really awesome quote</span>”</p>

 

Art C

Arthur Clifford

 

---

From: public-html-comments-request@... [mailto:public-html-comments-request@...] On Behalf Of Ryan Roberts
Sent: Friday, September 04, 2009 3:11 PM
To: Ian Hickson
Cc: public-html-comments@...
Subject: Re: HTML5's Q element

 

Ian Hickson wrote:

On Fri, 4 Sep 2009, Ryan Roberts wrote:

If you want quote marks in the source, use quote marks in the source, 

and don't use<q>.

If you want quote marks added automatically, use<q>.

This makes little sense. What you're saying is <q> has no semantic 

purpose anymore, it's there for presentation (see your further down).

I'm not sure what you mean by "semantic purpose". In what sense is all of 

HTML not just "there for presentation"?

The whole point of HTML is to be a media-independent, platform- 

independent, stylable documenta and application language. Presentation (on 

multiple media, devices, etc) is the most important use case.

Maybe I'm not explaining myself properly, I'm just a web designer and nobody fancy. I believed many if not most elements such as <q>, were there to describe the content. I see now this isn't the case with <q>, but it's only really like that because it's broken and nobody wants to fix it.

It would be stupid of us to try to change this now given that all four 

major browsers ship with a<q> that inserts quote marks. This was 

discussed in depth last year, and the spec was changed (from not 

inserting quotes to inserting quotes) after it was concluded that 

swimming against the browser vendors here was futile.

Then hand the spec over to them.

In what sense have we not handed the spec over to them? Browser vendors, 

as the most high-profile implementors of the spec, have full control over 

what ends up being implemented. I'm not going to make the spec say 

somethin they won't do; that would just turn the spec into an especially 

dry form of science fiction.

I understand that they have final say over what goes in their browsers, but I can't say I like them having final say over the HTML5 spec itself.

At this point, the<q> element's purpose is to enable CSS-based 

quotation mark injection. If you don't want that, then don't use<q>.

So at this point how do you mark up an inline quote?

One of the following:

   <p>Ryan asked "So at this point how do you mark up an inline 

   quote?"</p>

   <p>Ryan asked <q>So at this point how do you mark up an inline 

   quote?</q></p>

In that case why not have <p> auto inert a period then we could have the following:

Ryan doesn't like what he's hearing.

<p>Ryan doesn't like what he's hearing</p>

Ryan

--
Web Designer

 

Web: http://ryanroberts.co.uk

Email: hello@...

Phone: [phone]

[T.J. Crowder]

Art,

I don't think we have it backward at all, quotes absolutely have
semantic value, not to mention the huge degree of individual and
cultural variation related to them.  As a 20+ year software engineer,
I can tell you I don't even want to come anywhere near writing code
around that quagmire.

But I *do* think Ian's point that this has been specified for over 10
years is the absolute last word (see my most recent note on this).  I
don't see respecifying it now, that would be asinine.

-- T.J.

2009/9/4 Arthur Clifford <art@...>:

> Ryan and TJ,
>
>
>
> I think you have things backward.
>
>
>
> In HTML tags are what identify the structure/content/semantics of a
> document. Quotation marks (“) have no semantic value at all. The q tag on
> the other hand identifies a section of text as being a quote. Since q tags
> identify something as a quote, as an object within the document, it makes
> more sense to affiliate the symbols to surround the quoted text during
> display with the objects themselves; meaning it makes more sense to have the
> q tag dictate quote marks. As a programmer I will tell you that if I wanted
> to identify quoted material I’d much rather parse a well-formed html
> document for a q and /q  tag than “ marks. Besides “ is not a quote mark in
> printing, there are open and closed quote marks.
>
>
>
> I understand the frustration regarding the argument that because the browser
> vendors do it that’s the way it is going to be. I also understand Ian’s
> perspective, but I would say the browser vendors went the way they did
> because it makes more sense from a development perspective and ultimately a
> user experience to do things that way. The syntax of any programming
> language first and foremost is designed to make parsing it for use by the
> software into a data structure. If you think of html as informing an object
> model, then your opinion about quotes and q-tags becomes more and more
> invalid. The current implementation of q is far more flexible for the
> greatest number of outputs and use-cases.
>
>
>
> Ian missed a method of styling quotes the way you want:
>
>
>
> <p>blah blah blah, “<span style=”RyanQuotes”>some really awesome
> quote</span>”</p>
>
>
>
> Art C
>
> Arthur Clifford
>
>
>
> ________________________________
>
> From: public-html-comments-request@...
> [mailto:public-html-comments-request@...] On Behalf Of Ryan Roberts
> Sent: Friday, September 04, 2009 3:11 PM
> To: Ian Hickson
> Cc: public-html-comments@...
>
> Subject: Re: HTML5's Q element
>
>
>
> Ian Hickson wrote:
>
> On Fri, 4 Sep 2009, Ryan Roberts wrote:
>
>
>
> If you want quote marks in the source, use quote marks in the source,
>
> and don't use<q>.
>
>
>
> If you want quote marks added automatically, use<q>.
>
>
>
> This makes little sense. What you're saying is <q> has no semantic
>
> purpose anymore, it's there for presentation (see your further down).
>
>
>
>
>
> I'm not sure what you mean by "semantic purpose". In what sense is all of
>
> HTML not just "there for presentation"?
>
>
>
> The whole point of HTML is to be a media-independent, platform-
>
> independent, stylable documenta and application language. Presentation (on
>
> multiple media, devices, etc) is the most important use case.
>
>
>
>
>
> Maybe I'm not explaining myself properly, I'm just a web designer and nobody
> fancy. I believed many if not most elements such as <q>, were there to
> describe the content. I see now this isn't the case with <q>, but it's only
> really like that because it's broken and nobody wants to fix it.
>
> It would be stupid of us to try to change this now given that all four
>
> major browsers ship with a<q> that inserts quote marks. This was
>
> discussed in depth last year, and the spec was changed (from not
>
> inserting quotes to inserting quotes) after it was concluded that
>
> swimming against the browser vendors here was futile.
>
>
>
>
>
> Then hand the spec over to them.
>
>
>
>
>
> In what sense have we not handed the spec over to them? Browser vendors,
>
> as the most high-profile implementors of the spec, have full control over
>
> what ends up being implemented. I'm not going to make the spec say
>
> somethin they won't do; that would just turn the spec into an especially
>
> dry form of science fiction.
>
>
>
>
>
> I understand that they have final say over what goes in their browsers, but
> I can't say I like them having final say over the HTML5 spec itself.
>
>
>
>
>
>
> At this point, the<q> element's purpose is to enable CSS-based
>
> quotation mark injection. If you don't want that, then don't use<q>.
>
>
>
> So at this point how do you mark up an inline quote?
>
>
>
>
>
> One of the following:
>
>
>
>    <p>Ryan asked "So at this point how do you mark up an inline
>
>    quote?"</p>
>
>
>
>    <p>Ryan asked <q>So at this point how do you mark up an inline
>
>    quote?</q></p>
>
>
>
>
>
> In that case why not have <p> auto inert a period then we could have the
> following:
>
> Ryan doesn't like what he's hearing.
>
> <p>Ryan doesn't like what he's hearing</p>
>
>
>
> Ryan
>
> --
> Web Designer
>
>
>
> Web: http://ryanroberts.co.uk
>
> Email: hello@...
>
> Phone: [phone]

[Arthur Clifford]

Quotes have semantic value when a human is reading a document (obviously);
however, HTML is not for humans to read. A well formed DOM will provide a
hierarchical data structure that takes care of describing the parts of a
document. In which case quote characters are not relevant to the HTML
experience. The q-tag is what is semantically significant to an HTML
interpreter and that interpreter can decide how best to present the content
for final consumption by the end user.

You actually argued against yourself with the cultural variation point.
Somebody else brought up localization recently, a q tag can have a different
style applied based on location and therefore provide the demarcation for
the quoted content that is appropriate for that locale, meaning greater
flexibility in allowing for the same content to be consumable in any
cultural context. Likewise, a different style can be applied for sending to
a professional printer where they may want the open and closed quote marks.

I agree with you that it is moot as far as this tag is concerned. But the
discussion speaks to the overall approach to defining the spec and what we
should reasonably ask for and expect. For instance, is there a similar tag
for exclamations? In Spanish an exclamation is preceded by an upside-down
exclamation mark and ended with a right-side up one (I realize I just
defined the exclamation mark I'm used to as 'right-side' up, no offense to
any international readers). One could argue that if quotes are defined for
the q-tag that similar styling should be available for exclamations. If the
browser-vendors aren't dictating that behavior, shouldn't they? If the
standard is grudgingly being tailored to suit the browser-vendors without
understanding their motives or their logic then we fail to benefit from the
advantages of what they asked for in other areas of the spec.

Art C
Arthur Clifford

-----Original Message-----
From: public-html-comments-request@...
[mailto:public-html-comments-request@...] On Behalf Of T.J. Crowder
Sent: Friday, September 04, 2009 3:49 PM
To: art@...
Cc: public-html-comments@...
Subject: Re: HTML5's Q element

Art,

I don't think we have it backward at all, quotes absolutely have
semantic value, not to mention the huge degree of individual and
cultural variation related to them.  As a 20+ year software engineer,
I can tell you I don't even want to come anywhere near writing code
around that quagmire.

But I *do* think Ian's point that this has been specified for over 10
years is the absolute last word (see my most recent note on this).  I
don't see respecifying it now, that would be asinine.

-- T.J.

2009/9/4 Arthur Clifford <art@...>:

> Ryan and TJ,
>
>
>
> I think you have things backward.
>
>
>
> In HTML tags are what identify the structure/content/semantics of a
> document. Quotation marks (“) have no semantic value at all. The q tag on
> the other hand identifies a section of text as being a quote. Since q tags
> identify something as a quote, as an object within the document, it makes
> more sense to affiliate the symbols to surround the quoted text during
> display with the objects themselves; meaning it makes more sense to have

the
> q tag dictate quote marks. As a programmer I will tell you that if I
wanted
> to identify quoted material I’d much rather parse a well-formed html
> document for a q and /q  tag than “ marks. Besides “ is not a quote mark
in
> printing, there are open and closed quote marks.
>
>
>
> I understand the frustration regarding the argument that because the
browser
> vendors do it that’s the way it is going to be. I also understand Ian’s
> perspective, but I would say the browser vendors went the way they did
> because it makes more sense from a development perspective and ultimately
a
> user experience to do things that way. The syntax of any programming
> language first and foremost is designed to make parsing it for use by the
> software into a data structure. If you think of html as informing an
object

> model, then your opinion about quotes and q-tags becomes more and more
> invalid. The current implementation of q is far more flexible for the
> greatest number of outputs and use-cases.
>
>
>
> Ian missed a method of styling quotes the way you want:
>
>
>
> <p>blah blah blah, “<span style=”RyanQuotes”>some really awesome
> quote</span>”</p>
>
>
>
> Art C
>
> Arthur Clifford
>
>
>
> ________________________________
>
> From: public-html-comments-request@...
> [mailto:public-html-comments-request@...] On Behalf Of Ryan Roberts
> Sent: Friday, September 04, 2009 3:11 PM
> To: Ian Hickson
> Cc: public-html-comments@...
>
> Subject: Re: HTML5's Q element
>
>
>
> Ian Hickson wrote:
>
> On Fri, 4 Sep 2009, Ryan Roberts wrote:
>
>
>
> If you want quote marks in the source, use quote marks in the source,
>
> and don't use<q>.
>
>
>
> If you want quote marks added automatically, use<q>.
>
>
>
> This makes little sense. What you're saying is <q> has no semantic
>
> purpose anymore, it's there for presentation (see your further down).
>
>
>
>
>
> I'm not sure what you mean by "semantic purpose". In what sense is all of
>
> HTML not just "there for presentation"?
>
>
>
> The whole point of HTML is to be a media-independent, platform-
>
> independent, stylable documenta and application language. Presentation (on
>
> multiple media, devices, etc) is the most important use case.
>
>
>
>
>
> Maybe I'm not explaining myself properly, I'm just a web designer and

nobody
> fancy. I believed many if not most elements such as <q>, were there to
> describe the content. I see now this isn't the case with <q>, but it's
only

> really like that because it's broken and nobody wants to fix it.
>
> It would be stupid of us to try to change this now given that all four
>
> major browsers ship with a<q> that inserts quote marks. This was
>
> discussed in depth last year, and the spec was changed (from not
>
> inserting quotes to inserting quotes) after it was concluded that
>
> swimming against the browser vendors here was futile.
>
>
>
>
>
> Then hand the spec over to them.
>
>
>
>
>
> In what sense have we not handed the spec over to them? Browser vendors,
>
> as the most high-profile implementors of the spec, have full control over
>
> what ends up being implemented. I'm not going to make the spec say
>
> somethin they won't do; that would just turn the spec into an especially
>
> dry form of science fiction.
>
>
>
>
>
> I understand that they have final say over what goes in their browsers,

but

> I can't say I like them having final say over the HTML5 spec itself.
>
>
>
>
>
>
> At this point, the<q> element's purpose is to enable CSS-based
>
> quotation mark injection. If you don't want that, then don't use<q>.
>
>
>
> So at this point how do you mark up an inline quote?
>
>
>
>
>
> One of the following:
>
>
>
>    <p>Ryan asked "So at this point how do you mark up an inline
>
>    quote?"</p>
>
>
>
>    <p>Ryan asked <q>So at this point how do you mark up an inline
>
>    quote?</q></p>
>
>
>
>
>
> In that case why not have <p> auto inert a period then we could have the
> following:
>
> Ryan doesn't like what he's hearing.
>
> <p>Ryan doesn't like what he's hearing</p>
>
>
>
> Ryan
>
> --
> Web Designer
>
>
>
> Web: http://ryanroberts.co.uk
>
> Email: hello@...
>
> Phone: [phone]

[T.J. Crowder]

Art,

I read the localization point exactly opposite to the way you do (the
author surely is in a better position to determine what punctuation is
best suited to their content), but I'm not sure that this conversation
is really serving a purpose anymore and am bowing out of it.

-- T.J.



2009/9/5 Arthur Clifford <art@...>:

> Quotes have semantic value when a human is reading a document (obviously);
> however, HTML is not for humans to read. A well formed DOM will provide a
> hierarchical data structure that takes care of describing the parts of a
> document. In which case quote characters are not relevant to the HTML
> experience. The q-tag is what is semantically significant to an HTML
> interpreter and that interpreter can decide how best to present the content
> for final consumption by the end user.
>
> You actually argued against yourself with the cultural variation point.
> Somebody else brought up localization recently, a q tag can have a different
> style applied based on location and therefore provide the demarcation for
> the quoted content that is appropriate for that locale, meaning greater
> flexibility in allowing for the same content to be consumable in any
> cultural context. Likewise, a different style can be applied for sending to
> a professional printer where they may want the open and closed quote marks.
>
> I agree with you that it is moot as far as this tag is concerned. But the
> discussion speaks to the overall approach to defining the spec and what we
> should reasonably ask for and expect. For instance, is there a similar tag
> for exclamations? In Spanish an exclamation is preceded by an upside-down
> exclamation mark and ended with a right-side up one (I realize I just
> defined the exclamation mark I'm used to as 'right-side' up, no offense to
> any international readers). One could argue that if quotes are defined for
> the q-tag that similar styling should be available for exclamations. If the
> browser-vendors aren't dictating that behavior, shouldn't they? If the
> standard is grudgingly being tailored to suit the browser-vendors without
> understanding their motives or their logic then we fail to benefit from the
> advantages of what they asked for in other areas of the spec.
>
> Art C
> Arthur Clifford
>
> -----Original Message-----
> From: public-html-comments-request@...
> [mailto:public-html-comments-request@...] On Behalf Of T.J. Crowder
> Sent: Friday, September 04, 2009 3:49 PM
> To: art@...
> Cc: public-html-comments@...
> Subject: Re: HTML5's Q element
>
> Art,
>
> I don't think we have it backward at all, quotes absolutely have
> semantic value, not to mention the huge degree of individual and
> cultural variation related to them.  As a 20+ year software engineer,
> I can tell you I don't even want to come anywhere near writing code
> around that quagmire.
>
> But I *do* think Ian's point that this has been specified for over 10
> years is the absolute last word (see my most recent note on this).  I
> don't see respecifying it now, that would be asinine.
>
> -- T.J.
>
> 2009/9/4 Arthur Clifford <art@...>:
>> Ryan and TJ,
>>
>>
>>
>> I think you have things backward.
>>
>>
>>
>> In HTML tags are what identify the structure/content/semantics of a
>> document. Quotation marks (“) have no semantic value at all. The q tag on
>> the other hand identifies a section of text as being a quote. Since q tags
>> identify something as a quote, as an object within the document, it makes
>> more sense to affiliate the symbols to surround the quoted text during
>> display with the objects themselves; meaning it makes more sense to have
> the
>> q tag dictate quote marks. As a programmer I will tell you that if I
> wanted
>> to identify quoted material I’d much rather parse a well-formed html
>> document for a q and /q  tag than “ marks. Besides “ is not a quote mark
> in
>> printing, there are open and closed quote marks.
>>
>>
>>
>> I understand the frustration regarding the argument that because the
> browser
>> vendors do it that’s the way it is going to be. I also understand Ian’s
>> perspective, but I would say the browser vendors went the way they did
>> because it makes more sense from a development perspective and ultimately
> a
>> user experience to do things that way. The syntax of any programming
>> language first and foremost is designed to make parsing it for use by the
>> software into a data structure. If you think of html as informing an
> object
>> model, then your opinion about quotes and q-tags becomes more and more
>> invalid. The current implementation of q is far more flexible for the
>> greatest number of outputs and use-cases.
>>
>>
>>
>> Ian missed a method of styling quotes the way you want:
>>
>>
>>
>> <p>blah blah blah, “<span style=”RyanQuotes”>some really awesome
>> quote</span>”</p>
>>
>>
>>
>> Art C
>>
>> Arthur Clifford
>>
>>
>>
>> ________________________________
>>
>> From: public-html-comments-request@...
>> [mailto:public-html-comments-request@...] On Behalf Of Ryan Roberts
>> Sent: Friday, September 04, 2009 3:11 PM
>> To: Ian Hickson
>> Cc: public-html-comments@...
>>
>> Subject: Re: HTML5's Q element
>>
>>
>>
>> Ian Hickson wrote:
>>
>> On Fri, 4 Sep 2009, Ryan Roberts wrote:
>>
>>
>>
>> If you want quote marks in the source, use quote marks in the source,
>>
>> and don't use<q>.
>>
>>
>>
>> If you want quote marks added automatically, use<q>.
>>
>>
>>
>> This makes little sense. What you're saying is <q> has no semantic
>>
>> purpose anymore, it's there for presentation (see your further down).
>>
>>
>>
>>
>>
>> I'm not sure what you mean by "semantic purpose". In what sense is all of
>>
>> HTML not just "there for presentation"?
>>
>>
>>
>> The whole point of HTML is to be a media-independent, platform-
>>
>> independent, stylable documenta and application language. Presentation (on
>>
>> multiple media, devices, etc) is the most important use case.
>>
>>
>>
>>
>>
>> Maybe I'm not explaining myself properly, I'm just a web designer and
> nobody
>> fancy. I believed many if not most elements such as <q>, were there to
>> describe the content. I see now this isn't the case with <q>, but it's
> only
>> really like that because it's broken and nobody wants to fix it.
>>
>> It would be stupid of us to try to change this now given that all four
>>
>> major browsers ship with a<q> that inserts quote marks. This was
>>
>> discussed in depth last year, and the spec was changed (from not
>>
>> inserting quotes to inserting quotes) after it was concluded that
>>
>> swimming against the browser vendors here was futile.
>>
>>
>>
>>
>>
>> Then hand the spec over to them.
>>
>>
>>
>>
>>
>> In what sense have we not handed the spec over to them? Browser vendors,
>>
>> as the most high-profile implementors of the spec, have full control over
>>
>> what ends up being implemented. I'm not going to make the spec say
>>
>> somethin they won't do; that would just turn the spec into an especially
>>
>> dry form of science fiction.
>>
>>
>>
>>
>>
>> I understand that they have final say over what goes in their browsers,
> but
>> I can't say I like them having final say over the HTML5 spec itself.
>>
>>
>>
>>
>>
>>
>> At this point, the<q> element's purpose is to enable CSS-based
>>
>> quotation mark injection. If you don't want that, then don't use<q>.
>>
>>
>>
>> So at this point how do you mark up an inline quote?
>>
>>
>>
>>
>>
>> One of the following:
>>
>>
>>
>>    <p>Ryan asked "So at this point how do you mark up an inline
>>
>>    quote?"</p>
>>
>>
>>
>>    <p>Ryan asked <q>So at this point how do you mark up an inline
>>
>>    quote?</q></p>
>>
>>
>>
>>
>>
>> In that case why not have <p> auto inert a period then we could have the
>> following:
>>
>> Ryan doesn't like what he's hearing.
>>
>> <p>Ryan doesn't like what he's hearing</p>
>>
>>
>>
>> Ryan
>>
>> --
>> Web Designer
>>
>>
>>
>> Web: http://ryanroberts.co.uk
>>
>> Email: hello@...
>>
>> Phone: [phone]
>
>
>