Re: [whatwg] Site-Wide Heading Element

[Barry Smith]

On Jun 23, 2015, at 22:57, Mark Simon  wrote:

Presumably, the correct element is h1 for the banner heading, but this
may be at odds with the notion that h1 should describe the specific 
page.

The banner title would be expected to be the same for most, if not all,
pages, while the h1 might be expected to be different for each page.

While we should not pay too much heed to the whims of search engines,
there is the notion that varying the h1 in pages is good for SEO. For
this reason many site owners and developers are reluctant to use the main
h1 as a banner title.

As far as I am aware, there is no suitable HTML(5) element for a
site-wide heading. I would like to see the introduction of such an
element. Here are some suggestions:

* The purpose of the element is to provide a semantically appropriate
container for a site-wide title.
*  From a behavioural point of view, it would be similar to an h1
element. That is, a block element with mostly text.
* There would be no other special default appearance, much like a
paragraph. CSS can handle the rest.
* There should only be one such element on a page, in the body
element. It may be nested inside another suitable element, such as a
header.

On  Jun 24, 2015, at 7:08, Jonathan Zuckerman  
wrote:


What would be the value of such an element? There is an aria-role for
"banner" I believe..


On Jun 24, 2015, at 5:03, Mark Simon  wrote:

There is also an aria-role for “article” but this doesn’t invalidate
HTML5’s article element. Section 1.4 makes it clear that it is
preferable for the host language to do the job itself.

In any case, the “banner” role would be more suited to something like a
div, which is what the header element is doing. The proposed element
would be more like h1.

How about h0? That would be more in the pattern of things.



When I build a website that is to have more than one page, and I want the
"banner" to be the same across all pages,  I use the  element with a
javascript file embedded inside, like this:


   


and the javascript file looks like this:

document.write('\
   \
   The Site Name\
   Site Tagline\
   \
');

This way the  element is still free to use as the main body heading in 
the document itself.


The default aria- role for the  element is , 
so you

do not need to set it.

Thank You,
Barry Smith

Re: [whatwg] HTML6 proposal for single-page apps without Javascript

[Barry Smith]

Hello,

I try to read every one of these mailing list emails,,, even though I don't 
respond.  However,  I think it is crying shame that the new  and 
other Interactive elements are not supported across all browsers.  The 
 and the  elements are a great way to bypass some 
javascript.  As a note to all browser vendors;  Get with the program

Thanks,
Barry Smith
Growing Web Developer

--
From: "Andrea Rendine" 
Sent: Friday, March 27, 2015 11:50 PM
To: "WHATWG" 
Subject: Re: [whatwg] HTML6 proposal for single-page apps without Javascript

> It's sad indeed, as it seems that best practices are seldomly followed and
> poor coding is the way.
> However,
>> some functionality ordinarily provided by JavaScript that now can be done
> by HTML5, e.g. the details tag and progress tag
> Actually  is "native" only in its attribute definition and
> default rendering. It still requires JS in order to access its @value in
> write mode.
> On the other hand, I suppose that complete implementation of  is
> delayed by the fact that it's defined in terms of shadow DOM, and no real
> DOM adjusting is expected for it. Not every browser is ready for this
> further level of interface, probably.
>
> 2015-03-28 3:45 GMT+01:00 Michael A. Peters :
>
>>
>>
>> On 03/27/2015 06:51 PM, Miles Fidelman wrote:
>>
>>>
>>> I've been reading through the discussion thread, all of which seems to
>>> jump immediately into the weeds of specific details of the proposal.
>>>
>>> I'm amazed that nobody has yet commented on the implicit premise, which
>>> I read as:
>>> - JavaScript is a processing pig
>>> - with the addition of a few, well-defined constructs to HTML, with
>>> support from browsers, we could do a lot of what we want (or what people
>>> are doing) - without the overhead imposed by JavaScript
>>>
>>> To me, this seems like a very good thing.  It seems like:
>>>
>>> - It's getting harder and harder to do simple things.  Too many
>>> JavaScript frameworks and libraries.  Too much complexity. Authoring
>>> should not require extensive programming skills. (Whatever happened to
>>> the read/write web?).
>>>
>>> - JavaScript seems to encourage poor programming style, or at least
>>> resource-intensive programming.  It seems like 2/3 of the web pages I
>>> visit either freeze up, or just take incredibly long to load. Granted,
>>> that a lot of this is this stems from all the little click monitoring
>>> apps, and widgets, and who knows what else people put on their pages -
>>> and waiting for those various sites to respond - but it's the
>>> proliferation of more and more JavaScript that enables this.
>>>
>>
>> In HTML5 some functionality ordinarily provided by JavaScript that now 
>> can
>> be done by HTML5, e.g. the details tag and progress tag, is still not
>> universally supported by modern browsers requiring JavaScript fallback.
>>
>> I don't know why it takes the browsers so long to implement, but it does.
>>
>> The problem with JavaScript is that fewer and fewer web devs care. Rather
>> than picking a framework (like jQuery) and sticking with it, they 
>> copypasta
>> JS they find around the web (often in violation of the license) and add
>> whatever framework that snippet depends upon.
>>
>> Few people care about passing their JS through tools like JSLint, and 
>> many
>> pages still have dozens of external JS references as well as numerous
>> inline scripts.
>>
>> They just don't care. And that is hard to fix with standards because they
>> don't care.
>>
>

[whatwg] Obsolete Feature [hgroup]

[Barry Smith]

 Hello, 

I have read where the W3C has made the hgroup element obsolete, 
http://www.w3.org/html/wg/drafts/html/master/obsolete.html#non-conforming-features
 .  I see the specification is still in the "WHATWG  HTML: The Living Standard" 
specifications.  Are there any plans to remove this element from the 
specification?  If not, as a web developer, I try extremely hard to follow 
protocol and create a valid and semantically correct document.  How should I 
handle this?

As far as validation, a document with the hgroup element will not pass when 
using the W3C Markup Validation Service.  However it will pass when using the 
https://html5.validator.nu/  validator.  Should I ignore the error I receive?


Thank You For Your Time,
Barry Smith