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

Re: <font color="blue"> (was ISSUE-32)

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 19 Jun 2009 12:38:20 -0700
Message-ID: <63df84f0906191238v27ab1e52j4c791a3586e22e99@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Rob Sayre <rsayre@mozilla.com>, Shelley Powers <shelley.just@gmail.com>, "Edward O'Connor" <hober0@gmail.com>, "public-html@w3.org WG" <public-html@w3.org>
On Mon, Jun 15, 2009 at 5:31 AM, Sam Ruby<rubys@intertwingly.net> wrote:
> Jonas Sicking wrote:
>>
>> On Mon, Jun 15, 2009 at 2:59 AM, Sam Ruby<rubys@intertwingly.net> wrote:
>>>
>>> Jonas Sicking wrote:
>>>>
>>>> On Sun, Jun 14, 2009 at 4:31 AM, Sam Ruby<rubys@intertwingly.net> wrote:
>>>>>
>>>>> Rob Sayre wrote:
>>>>>>
>>>>>> On 6/9/09 10:52 PM, Sam Ruby wrote:
>>>>>>>
>>>>>>> Rob Sayre wrote:
>>>>>>>>
>>>>>>>> On 6/9/09 6:02 PM, Shelley Powers wrote:
>>>>>>>>>
>>>>>>>>> Why reference the Mozilla API? I'm assuming because it drives the
>>>>>>>>> Mozilla editor, as well as the browser, which puts the API into the
>>>>>>>>> conforming author territory, while still being part of a user
>>>>>>>>> agent.
>>>>>>>>
>>>>>>>> That's a good point. Just more fallout from the ridiculous author
>>>>>>>> conformance requirements. Pseudo-intellectual ideas about "semantic
>>>>>>>> markup"
>>>>>>>> just don't buy you that much as requirements.
>>>>>>>>
>>>>>>>> Like anything else, some HTML files are better crafted than others,
>>>>>>>> but
>>>>>>>> conformance requirements should address showstoppers.
>>>>>>>
>>>>>>> Are there MUSTs in the current spec that the Mozilla foundation is
>>>>>>> unlikely to ever implement?  Can they be identified specifically?
>>>>>>
>>>>>> Yes, most of the authoring requirements are meaningless or at least
>>>>>> pointless. I hope you can forgive me for failing to produce an
>>>>>> exhaustive
>>>>>> list, but the subject of this message is a good example.
>>>>>
>>>>> Just to be clear: the subject of this messages is an example of
>>>>> something
>>>>> that absolutely prevent one or more products that aspires to be HTML 5
>>>>> conformant from ever being so?  Do I have this correct?  Do others at
>>>>> Mozilla agree?
>>>>
>>>> While I think it's an interesting idea, I'm not convinced it's
>>>> practical. I certainly agree that author conformance is a very weak
>>>> concept, and that most authors are not going to care if leave the spec
>>>> the way it is, or if we leave it up to the community to create some
>>>> sort of lint too, or if we say nothing about what is conformant and
>>>> what is not.
>>>>
>>>> But I'm actually more worried about how the standards community would
>>>> cope. Though it's entirely possible to it'd cope better than it does
>>>> now (avoiding rat-hole about what should be valid and what shouldn't).
>>>>
>>>> Another problem that we'd have to solve is what recommendations to
>>>> give to authoring tools. Right now we can tell them to output
>>>> conforming documents, but if that concept disappears we'd have to
>>>> replace it with something else.
>>>
>>> Forgive me, it is not clear to me how that response relates to my
>>> questions.
>>>
>>> Is there or is there not any product produced by Mozilla foundation that
>>> would be considered to be an authoring tool or markup generator that can
>>> be
>>> used to produce markup containing a font element?
>>
>> Ah, yes, it appears I misunderstood your question.
>>
>> Firefox does have code that deals with HTML authoring. I'm not sure if
>> that code specifically will output <font> tags, or if it only exposes
>> an API for surrounding text with an arbitrary element. Or if it's
>> something inbetween, such as it only exposes such an API, but that
>> it's aware that <font> is an inline element or some such.
>>
>> Then there is Thunderbird which allows you to author HTML mail, and
>> which I just tested does output <font> tags.
>>
>> Finally there is Composer which is a pure HTML editor, and which I'm
>> fairly certain in certain modes will output <font> tags. Though I
>> think the default behavior is not to, but I'm just working on vague
>> memories on that.
>>
>> (Technically speaking mozilla doesn't produce a "product" with
>> Composer in it, just a platform which others turn into a product, but
>> that distinction I don't think is important here. Similarly, mozilla
>> foundation doesn't output any product, just technologies. It's
>> subsidiaries of the foundation that ship firefox and thunderbird. But
>> again, I don't think the distinction is relevant to this discussion).
>>
>> So yes, we do currently ship products that do not conform to HTML 5
>> when it comes to authoring requirements. I do hope that this is
>> something that we'll look into and fix as appropriate (amend the spec
>> or file and fix bugs). Just like we today don't nearly follow conform
>> to the HTML 5 parsing algorithm, but are working on fixing that.
>>
>> Possibly thunderbird would have to keep outputting <font> elements if
>> other mail clients don't support @style as well as <font>.
>>
>> I hope that I got your question correct this time :)
>
> Yup.  :-)
>
> But you didn't answer it.  :-P
>
> The specific question: "amend the spec or file and fix bugs"?  Which do you
> (Jonas) think is more appropriate in this instance (font color)? Don't worry
> about the current state of tools or timeframes: what I am curious about is
> your thoughts on what the long term goal should be.

I would be for making us not insert <font color> in the cases where
this is possible. So if we expose a API for setting color while
composing, I would support that not inserting a <font> tag.

In places where we're exposing APIs to insert a specific element, with
specific attributes, then it's not much we can do. The webpage is in
full control to insert a <font>, <center> or <smorgasbord> element :)

/ Jonas
Received on Friday, 19 June 2009 19:39:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:04 UTC