HTML 5

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

HTML 5

mbtawes

To whom it may concern:

 

I have been using HTML for almost 6 years now, and I always have used the <b>, <u>, <i>, <font>, <s> or <strike>, and <center> elements because they allow for easy-to-read code and simpler editing. For example, I think that

<b>some text</b>

is much simpler than:

<span class="bold">some text</span>.

 

I also think that the align, alink, vlink, link, text, background, bgcolor,hspace, border, vspace, type, valign, width, height, cellpadding and cellspacing attributes for their respective elements are very useful and should not be eliminated. I think that HTML5 should be HTML5, not plain text with CSS.

 

Please do not remove these elements and attributes.

Thank you,

Michael Tawes

Webmaster

Troop 918

http://www.ourshepherd.com/bsatroop918/default.htm

Reply | Threaded
Open this post in threaded view
|

Re: HTML 5

Michael[tm] Smith
In response to the following message:

  http://www.w3.org/mid/583786989.941443.1306443252301.JavaMail.root@...

... the following bug has been raised in the W3C Bugzilla database:

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=12803

You are encouraged to add yourself to the CC List for the bug -- which
will require that you create a W3C Bugzilla user account (if you don't
have one already):

  http://www.w3.org/Bugs/Public/createaccount.cgi

Reply | Threaded
Open this post in threaded view
|

Re: HTML 5

T.J. Crowder
Hi,

Is the current practice is to comment in the mailing list or on the bug report?

`b`, `i`, `u`, and `s` (strikethrough) are all currently in the specification[1].

`font` was always broken, IMHO, particularly the `size` feature. I think applying CSS to something semantic wherever possible, and falling back on an introduced span if necessary, is best.

`center` *should* have a viable CSS alternative, it's purely presentational. I've heard people saying they still want/need `center` though (here[2], for instance). For just text centering, of course there's `text-align`, and for centering elements there's `margin-left: auto; margin-right: auto;` (which results in the element being centered within its parent, subject to some caveats; details[3]). Are there cases where one of those isn't sufficient?

--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com


On 28 May 2011 09:42, Michael[tm] Smith <[hidden email]> wrote:
In response to the following message:

 http://www.w3.org/mid/583786989.941443.1306443252301.JavaMail.root@...

... the following bug has been raised in the W3C Bugzilla database:

 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12803

You are encouraged to add yourself to the CC List for the bug -- which
will require that you create a W3C Bugzilla user account (if you don't
have one already):

 http://www.w3.org/Bugs/Public/createaccount.cgi


Reply | Threaded
Open this post in threaded view
|

Re: HTML 5

Michael[tm] Smith

"T.J. Crowder" <[hidden email]>, 2011-05-28 10:57 +0100:

> Is the current practice is to comment in the mailing list or on the bug
> report?

If you're following up on a comment somebody else posted to this list, it's
fine to post here. You're also welcome of course to post your follow-up as
a comment in the relevant bugzilla bug.

  --Mike

--
Michael[tm] Smith
http://people.w3.org/mike

Reply | Threaded
Open this post in threaded view
|

Re: HTML 5

Jukka K. Korpela-2
In reply to this post by T.J. Crowder
28.5.2011 12:57, T.J. Crowder kirjoitti:

> Is the current practice is to comment in the mailing list or on the bug
> report?

That's what I wonder too. Both ways are supposed to work, but that's not
really an answer.

> `b`, `i`, `u`, and `s` (strikethrough) are all currently in the
> specification[1].

All with completely rewritten semantics. Most probably, few authors will
pay any addition to the new, rather contrived semantics and will keep
using those elements for physical markup the old way.

This means that anyone who wishes to conform to HTML5 in old documents
should revise _all_ use of such markup and replace it either by
appropriate semantic markup, such as <strong>, <em>, or <cite>, or with
the use of CSS. In _rare_ cases, preserving <b>, <i>, etc. might be the
right move, as the intended meaning _accidentally_ coincides with the
new definition.

That's the theory, and I think it does not have much chance of becoming
reality. It will cause some confusion among a semantics-oriented
minority, not much more.

Here's how I would define the <b> element, for example:

The <b> element indicates bold text. In situations where bolding cannot
be used, user agents may ignore <b> markup or render it in a manner that
is widely understood by users as simulating bolding. Authors should not
use the <b> element except when quoting external sources (such as
printed matter) containing bold text and for texts that are rendered in
bold by convention, such as vector symbols in mathematics.

> `font` was always broken, IMHO, particularly the `size` feature. I think
> applying CSS to something semantic wherever possible, and falling back
> on an introduced span if necessary, is best.

I don't see why anyone would miss the <font> element, except in
situations where you need to format HTML documents without CSS, and such
situations are rare. The only situation where font would actually make
sense is a context where the text _discusses_ fonts and shows examples
of texts in different fonts. Then it's a matter of content, not just
casual style preference. But this case is probably too rare to have an
impact.

> `center` *should* have a viable CSS alternative

<Center>...</center>, being formally equivalent to <div
align="center">...</div> but implemented inconsistently, has always been
a problem.

The original poster had a long wishlist (the attributes align, alink,
vlink, link, text, background, bgcolor,hspace, border, vspace, type,
valign, width, height, cellpadding and cellspacing), so I guess he
basically meant that presentational markup should not be obsoleted. It
is probably too late now, though some details are still under
consideration and some presentational markup might be "saved".

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Reply | Threaded
Open this post in threaded view
|

Re: HTML 5

Jens Oliver Meiert
In reply to this post by mbtawes
> I have been using HTML for almost 6 years now, and I always have
> used the <b>, <u>, <i>, <font>, <s> or <strike>, and <center>
> elements because they allow for easy-to-read code and simpler
> editing.
>
> I also think that the align, alink, vlink, link, text, background,
> bgcolor,hspace, border, vspace, type, valign, width, height,
> cellpadding and cellspacing attributes for their respective elements
> are very useful and should not be eliminated.

Not sure this point got much attention: the reason why it’s not
advisable to use any presentational markup is that it’s harder to
maintain (shameless: [1]).

How presentational markup is easier to read is not clear to me: using
more code typically does but one thing, making it harder to understand
the code, and if you want to understand how a document will look like,
the answer should be made by the style sheet.


[1] http://meiert.com/en/blog/20090617/maintainability-guide/#toc-markup

--
Jens O. Meiert
http://meiert.com/en/

Reply | Threaded
Open this post in threaded view
|

Re: HTML 5

Jukka K. Korpela-2
3.6.2011 6:08, Jens O. Meiert wrote:

> Not sure this point got much attention: the reason why it’s not
> advisable to use any presentational markup is that it’s harder to
> maintain

The arguments against presentational markup vary a lot, apparently due
to varying estimates on what might be the best tactics. In this respect,
they resemble religious attitudes and cultural prejudices.

In which sense is <b>foo</b> harder to maintain than <span
class="bold">foo</span>?

What might the difference in maintenance difficulty be if in both cases
the markup is actually automatically generated, using preprocessing or
server-side technology, and is never modified directly?

> How presentational markup is easier to read is not clear to me: using
> more code typically does but one thing, making it harder to understand
> the code, and if you want to understand how a document will look like,
> the answer should be made by the style sheet.

Finding how a style sheet might modify rendering is surely more
complicated, and often _much_ more complicated, than understanding the
rendering effect of presentational markup.

While <span class="bold">foo</span> might seem obvious, you are just
making a guess. If the author has been more structural and has actually
written <span class="avainsana">foo</span>, you would understand the
intended meaning (assuming you know the language from which the author
picked up the semantic name for the class, of course) but would have
little clue of the rendering.

Presentational markup is honored by current and future browsers, out of
necessity of dealing with billions of existing pages. Therefore, authors
can and will use it if they find it useful and easier to use than the
alternatives (if they even know the alternatives). The way to propagate
good authoring habits – which is what this is really about – is to give
them better tools, packaged better, and to teach them.

Removing presentational markup from specifications does not really help
anyone, except in the sense that it may bring the feeling of having done
Something, or at least trying something. And HTML5 is’t even removing
it, just throwing it into the dark side. HTML 4.01 is confusing, with
its Transitional, Strict, and Frameset DTD and “deprecation”, which
almost (but not completely) coincides with not being Strict. HTML5
replaces that stuff with other concepts, which are not necessarily easier.

However, reopening the whole issue of presentational markup would
probably just slow down the process and cause endless debates, if not
worse. Authors have lived with HTML 4.01, perhaps ignoring parts thereof
and learning from other sources that parts thereof are dead letters, and
authors can live with HTML5.

But if specific issues related to specific “presentational markup”
(itself a vague concept) are raised, it would be best if we all could
put our beliefs, taste for style, and habits aside – and concentrate on
specific pros and cons. For example, border="1" is now allowed in
<table>, despite many people’s attitudes against any presentational
markup. There were specific arguments that made that possible, and the
quasi-semantic description that was adopted probably helped in the
process. So anyone who wants to get some of e.g. “align, alink,...” into
approved HTML5 should carefully consider what is really needed and find
strong and specific arguments in favor of it.

--
Yucca, http://www.cs.tut.fi/~jkorpela/