Today, I learned that display: block on a <summary> element removes the disclosure triangle in Firefox.
html5 posts
Conference: Rustbelt Refresh
in
WWW
conference
css
html5
I went to my first real full length web development conference today, Rustbelt Refresh. It was a very good conference with good speakers and interesting topics. Finally something like this in Cleveland. I learned and got to thinking about various things. I was rather tired though after waking up so early and spending a whole day there. I will summarize / talk about each presentation, as sort of a minimal review, but primarily to store and cement what I’ve taken away in my mind.
Presentations
Eric Meyer: The Era of Intentional Layout
Eric Meyer is our local global CSS celebrity. I’ve gone to every local presentation he gave that I was aware of, which I think totals three with this one.
His talk started with a history of CSS layout, and how CSS never got a real layout system and the things we still use today are mostly hacks, limited in what can be done with them, and often create problems. To summarize this history: At first the web had no layout, and content just went with the flow. Then tables came in for tabular data. They quickly became used for layout because of the lack of alternatives, and soon made markup a nested mess that was difficult to maintain and impossible to change the layout without changing the site structure. Floats were added to allow content to flow around things like images, and quickly became usurped for layout. Since they were designed without layout in mind, they had a lot of problems in use for it, and a lot of creative hacks have been created to get around them, like equal height columns and zero height containers. Then came positioning, which was actually designed for layout, but had the problem of taking things out of flow and thus not allowing things to move in relation to each other, etc.
Continue reading post "Conference: Rustbelt Refresh"HTML5: The Progress Element
I decided to attempt to use another new HTML 5 element on a site, the <progress> element. This element is used to show the completed progress of a task, perfect for the tasks in a project management application we are making at Cogneato. I wanted it to have the same appearance for all modern browsers, a visual bar indicating percentage complete of a fixed width total bar. As always, this required some special handling for different browsers. Because of the complications, I needed to output different markup for different browsers, so I made a PHP function using server side browser sniffing to give me the proper output. The convoluted function looks like this:
<?php
$glbProgressWidthModifier=0.8;
function generateProgress($value){
global $glbProgressWidthModifier, $ischrome, $issaf, $isie, $isie9;
$value = $value * 100;
ob_start();
?>
<?php if(!$ischrome){ ?><div class="progresswrap">progress value="" max="100" class="elmprogress" style="width:px;"><span>%</span>></div><?php } ?>
<?php
$fncReturn = ob_get_contents();
ob_end_clean();
return $fncReturn;
}
with a global width modifier to set the width of the total bar, where 1 means 100px, and various is… variables set elsewhere based on the sniffed browser. It will return the HTML output given a numeric value between 0 and 1 representing percentage complete, like echo generateProgress(0.85).
HTML5 href Anywhere Attempt
XHTML 2 was going to allow use of the href attribute on any element, allowing for block level anchors and eliminating repetition of the same anchor in some cases or unnecessary additional tags in others. This really made sense, since the <a> tag is just a span, but the only span with an added ability of linking to somewhere else. There is really no special semantic meaning to the <a>, and all links on a page could be found in parsing by finding tags with the href. In the early days of the development of HTML 5, the “href anywhere” approach was discussed, and I was excited thinking it was going to be part of HTML 5. At the time, that was the most interesting thing about HTML 5 to me. But “href anywhere” would mean all previous browsers would not be able to see links at all (besides for the ones put in <a> tags for some reason), so the idea was scrapped. Instead, the HTML 5 creators took advantage of an against-spec ability that current browsers already had: block level anchors. Browsers at least back to IE 6 will happily make “flow content” placed in an <a> tag into a link.
I was somewhat unhappy that we had to kowtow to current browsers by preventing such a wonderful ability as href’s on any tag, but the backwards compatibility thing is huge in real world development (though I would have just done some server side browser sniffing to output the <a>‘s in appropriate places for incompatible browsers) and the solution handles most use cases, though with a bit of extra markup. Over time, I began thinking that perhaps I could just use <a>‘s in place of any tags that have no semantic meaning (ie <div> and <span>), only using href when required and thus have href available most anywhere.
Haley Litzinger: HTML 5 Semantic Elements
It looks like I will not be doing at least the design for Haley’s site. She just got Adobe Suite CS3 and wants to make use of it. I will probably be helping her out at least some with it though, and we may even use her design on the WordPress site I built for her. We still haven’t met to discuss the details of this yet though.
Before I found out about her plans to build or at least design the site, I built a simple but functioning test site. In doing so, I made my first venture into using the new HTML 5 semantic elements. I used the Dive Into HTML 5 site along with a few others to learn how to use the elements. The new elements I made use of are “section”, “header”, “footer”, “nav”, “hgroup”, and “time”. There’s also the “article”, “aside”, “mark”, “figure”, “meter”, etc. tags, but I did not use them on this site. The Dive Into HTML 5 site describes the basic ones fairly well in brief.
Continue reading post "Haley Litzinger: HTML 5 Semantic Elements"TMCom: Now Real XHTML 5
As mentioned in a previous post, my site has gone to the HTML 5 doctype. I had come from XHTML 1.0 and wanted to continue with the XML syntax of HTML 5, but my site wouldn’t validate with the XML declaration. I recently remembered that I had been serving my site with the mime-type “text/html”, which is allowed in XHTML 1.0 transitional. HTML 5 got stricter, and if you want to use the XML syntax, it must be served as “application/xhtml+xml” or “application/xml”.
So I modified the doctype switcher I had made (mentioned in that previous post) to change the mime-type to “application/xhtml+xml” when the configuration doctype was set to “xhtml5”. But IE evidently cannot handle that mime-type, so I set up my switcher to output as “html5” for IE, but “xhtml5” for other browsers. I reset the doctype variable (now an attribute of a page object):
if($this->doctype == 'xhtml5' && strstr($_SERVER['HTTP_USER_AGENT'], 'MSIE'))
$this->doctype = 'html5';
TMCom Goes HTML 5 (Doctype anyway)
I’ve finally joined the bandwagon and moved my site to the HTML 5 doctype. It is much simpler than previous doctypes:
<!DOCTYPE html>breaking away from the SGML standard of including a reference to the DTD for that doctype. I’m not sure how this will play out as HTML moves beyond 5, but I’m sure it won’t be a problem for a while anyway. And hopefully with all this time they are taking to finalize the specifications, we won’t have problems with backward compatibility, future expansion, validation of old documents, etc.
Anyway, I had considered using the doctype a while back but abandoned it for reasons I don’t remember. The “role” attribute, which I first noticed in WordPress themes, is what got me to consider HTML 5 again. It offers potential accessibility benefits to user agents that know about it by specifying what an elements “role” is in relation to its document: navigation, banner, main, contentinfo, etc. HTML 5 offers elements with similar meanings, but they are not supported well. The attribute is not valid in XHTML 1 (it was proposed for XHTML 2, which never came about), and my attempts at an alternative doctype failed.
Continue reading post "TMCom Goes HTML 5 (Doctype anyway)"