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

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.

This is an instance of a more general question, but lets explore that 
after we resolve the specific question.

> / Jonas

- Sam Ruby

Received on Monday, 15 June 2009 12:32:19 UTC