W3C home > Mailing lists > Public > public-html@w3.org > June 2008

Re: ISSUE-48 (marks-content-markup-attribute): 'marks' content markup attribute for Q (quotation) and BLOCKQUOTE [HTML 5 spec]

From: Robert J Burns <rob@robburns.com>
Date: Mon, 2 Jun 2008 12:09:09 +0000
Cc: HTML Issue Tracking WG <public-html@w3.org>
Message-Id: <84CB0385-725F-43E8-BCD3-14381666E58C@robburns.com>
To: Andrew Sidwell <w3c@andrewsidwell.co.uk>

Hi Andrew,

On Jun 2, 2008, at 12:08 AM, Andrew Sidwell wrote:

>
> Robert J Burns wrote:
>> Hi Andrew,
>> On May 29, 2008, at 3:48 PM, Andrew Sidwell wrote:
>>>
>>> HTML Issue Tracking Issue Tracker wrote:
>>>> For Q (quotation) and BLOCKQUOTE a 'marks' content markup  
>>>> attribute.
>>>> Permits authors greater control over the separation of concerns of
>>>> styling quotations and specifying the semantics of quotations  
>>>> within a
>>>> document. Also allows authors to work around the current state of
>>>> interoperability across popular UAs.
>>>> for more detailed discussion, please consult the wiki page at: http://esw.w3.org/topic/HTML/AddedAttributeQuotationMarks
>>>
>>> The use-case here is authors wanting to mark up quotes.  There are  
>>> two plausible ways of implementing it: just choose one and be done  
>>> with it.  Sure, <q> has interoperability issues, so pressure IE to  
>>> fix it or the other browsers to stop using quotes; don't invent a  
>>> new attribute to permanently embed this weird situation in the  
>>> specification.  (Just because other weird things are in now  
>>> mandated by the spec doesn't mean that we should keep on adding  
>>> weird things to that list.)
>>>
>>> Whilst I appreciate that hypothetically it would be nice for some  
>>> people to specify which way they want things, in practice it won't  
>>> be a) useful or b) even make a difference to the vast majority of  
>>> authors, so increasing implementation complexity for such a tiny  
>>> gain seems, well, silly.  (See "Solve Real Problems".)
>> I get the feeling you're not taking the time to understand these  
>> issues before responding to them. You should understand that this  
>> proposal requires zero implementation whatsoever,
>
> We must have different ideas of what implementation means.

Well why don't you tell me how you're using it here. As I've said  
already this requires a single CSS declaration in the UAs default  
stylesheet for UAs that support CSS ::before and ::after selectors.

q[marks=provided]::before,
q[marks=needed]::after {
	content: "";
	
}

Is that what you mean by implementation? Is that what you mean by  
implementation complexity? I would call that a stylesheet declaration  
having little to do what most other people refer to when they talk  
about "implementation complexity". Keep in mind too that this is  
optional. It would be perfectly acceptable to simply give authors this  
fix (one they could come up with on their own, but this provides an  
official W3C endorsement and gives them conformance checking for it).  
So in that sense it requires no implementation from UAs whatsoever.  
All those UAs already supporting CSS ::before and ::after will already  
handle this for authors. Likewise since its meant to patch a problem  
with UAs that do not support CSS ::before and ::after, they too  
require no implementation.

So please explain to me what you mean by implementation.



> > let alone leading to too much implementation complexity.
>
> Any changes that are useless have too much implementation complexity.

Would you care to maintain some level of decorum here. Calling others  
ideas useless does not help anything. Since it is clear you don't  
understand what it is for, you're simply embarrassing yourself saying  
such things.

> > For those UAs already supporting CSS :before
>> and :after and attribute selectors and content generation, the only  
>> thing required is a change to the UAs default stylesheet.   How can a
>> minor change to an implementation stylesheet like that possibly  
>> trump the needs of authors and users.
>
> I don't buy into the idea that authors need to have whether the  
> browser should include quote marks around element content baked into  
> the syntax of the language.  They need to mark up quotes, fine--  
> they can do that.

They need to markup quotes in a way that works across browsers whether  
they support CSS ::before and ::after or not. That issue aside, there  
is a difference of opinion from authors about which is the right  
approach. This allows that to be properly expressed in the semantics  
of an HTML document and allows both author and user stylesheets to do  
the right thing.

>> As for telling authors to make up their mind, that's just silly.There
>> are clearly reasonable arguments for both quotations as punctuation  
>> and quotations as a matter of style.
>
> Indeed, so choose one or the other rather than being wishy-washy and  
> having both.  If we applied the philosophy of "where there are  
> reasonable arguments for doing things one of two ways, allow both",  
> the spec would be insanely bloated.  (Assuming it's not already,  
> which some people think it is. :)

The spec is insanely bloated. This does nothing about that issue one  
way or the other.

>
> My point is merely that given there is no actual gain in allowing  
> authors to specify whether they want the browser to add quotes or  
> have added them themselves, introducing such a feature *at all* is  
> needless complexity.

But there is actual gain. If I'm writing a user stylesheet how do I  
know whether to add quotes to the quotation elements or not. I do not  
know. I may end up adding the redundant quotes to the document.

> > This simple proposal meets the needs of
>> both authors while requiring authors happy with the current  
>> situation of quotations as matter of style to do nothing with their  
>> content. I am quite astonished that this proposal could face any  
>> controversy whatsoever.


Take care,
Rob
Received on Monday, 2 June 2008 12:09:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:55 UTC