Issues tagged with 'HTML5'

We agreed on a few things in the jQuery issue #1541860: Reduce dependency on jQuery This is the meta tracking the progress. What this aims at is a full review of our JS code.

What we agree on, in order of most important for perfs:

1. #1279226: jQuery and Drupal JavaScript libraries and settings are output even when no JS is added to the page
2. Look at all our selectors and HTML structure and see how that can be simplified to allow better, faster selectors.
3. don't use sizzle-specific selectors if we can avoid it.
4. use regular for loops when $(seletor).each() is overkill. Separate the selecting and processing of elements. Typically it means removing the anonymous function when using .once().

The plan is to open an issue for each core file/module and tackle points 2-4 one file at a time.

misc/ ajax.js [#] authorize.js #1574484: Selectors clean-up: authorize.js autocomplete.js [#] batch.js #1574490: Clean-up: batch.js collapse.js [#] form.js [#] machine-name.js [#] progress.js [#] states.js [#] tableselect.js [#] timezone.js #1574696: Selectors clean-up: timezone.js vertical-tabs.js [#] modules/ block #1574512: Selectors clean-up: block book #1574620: Selectors clean-up: book color [#] comment [#] contextual [#] dashboard [#] field/modules/text [#] field_ui [#] file [#] filter [#] locale [#] menu [#] node [#] openid [#] overlay [#] shortcut [#] simpletest [#] statistics Already ok system [#] taxonomy [#] toolbar [#] user [#] themes/ bartik/color [#]

Some that are not selectors specific:

misc/ drupal.js #1089300: Clean up drupal.js tabledrag.js #1524414: Rewrite tabledrag.js tableheader.js #1574738: Rewrite tableheader.js

I've highlighted the ones that would benefit the most. The changes to tabledrag are a bit more drastic than the rest so we might to keep it for the end since it's such a big piece of code.

Feel free to edit and add links to issues. Don't forget to add the "JavaScript Clean-up" tag to every issue you might open for this.

This has been bothering me in 7 for a little bit now. In 8 we no longer need the embed prefix we put in inline css/js.

Just to make it clear I'm talking about this:

<!--//--><![CDATA[//><!--
//--><!]]>

Anyways here's a 1st attempt at it.

I'm pretty sure this will failed some test.

AttachmentSizeStatusTest resultOperations cdata.patch2.77 KBIdleFAILED: [[SimpleTest]]: [MySQL] 35,353 pass(es), 3 fail(s), and 64 exception(s).View details | Re-test

While reading the specs for #1445224: Add new HTML5 FAPI element: color I found that some attributes are not allowed for the new input types (making for invalid HTML).

• #1174640: Add new HTML5 FAPI element: number:
  1. size is not allowed.
  2. maxlength is not allowed.
• #1174646: Add new HTML5 FAPI element: range:
  1. size is not allowed.
  2. required is not allowed. The element always has a value.

Reference for the specific states: http://www.w3.org/TR/html5/number-state.html

Follow up of #1174646: Add new HTML5 FAPI element: range.

If a browser doesn't support the range element at all, everything is fine: A textfield is displayed instead.

However some webkit based browsers, including Androids stock browser seem to hide the range element, which is really bad. That can be overriden with CSS.

So we need someone design and CSS savvy to style the element.

Resources:

• http://tiffanybbrown.com/2012/02/07/input-typerange-and-androids-stock-b...

The recently addition of "required" attributes to the username and password fields (see #1174938: Natively support the HTML5 #required FAPI property) has made it impossible to log in with OpenID, because the two fields are just hidden but not disabled.

This patch remove the #required attribute for the username and password fields and instead set the attribute via JavaScript. It also includes a fix for #897794: OpenID login link can hide the wrong fields and incorporates most things from the patch in that issue.

AttachmentSizeStatusTest resultOperations openid-required-1.patch4.96 KBIdlePASSED: [[SimpleTest]]: [MySQL] 35,068 pass(es).View details | Re-test

TL;DR

New IE8 features will break the JS on IE7/6. The features have a very big positive impact on performance, we would benefit a lot from them. I'm asking how committed we are with IE8 in D8.

First

Can the javascript crash under IE7/6, potentially preventing every other JS from running on the page?

Second

How painful we want to make IE6/7 support for contrib. In order of PITA: to support IE6/7 contrib would have to:

1. Replace files: Replace all problematic core js files with compatible version.
2. Preprocess files: Preprocess the js file and do a search/replace (It'll be possible to do, it's just changing the function name with $).
3. Replace functions: Replace a few core JS functions to replace them with compatible alternatives.

I need both answers to continue with the Core clean-up of JS files.

Original report

Drupal 8 will support only IE8+, this is great news. The real world may have to support IE6/7 for a while longer though.

IE8 allows us to use very nice things like querySelectorAll, localStorage, console.log, JSON. A number of these new things can speed up js so much it needs to be plotted on a logarithmic scale (true story). I very much intend to use them as much as possible.

Using that means that the page completely fails in IE6/7. Since the front-end might depend on some core code and said front-end might need to be IE6/7 compatible, how are we going to handle that? It's not the same as requiring a minimum PHP version.

On the code side we can wrap all functionalities in a function call that can be overridden by contrib. Honestly I'd prefer if we let contrib deal with that (backport module?) and override the whole js file to make it compatible for dumb browsers.

It's critical because in China for example they are still using IE6 an it still has a big market share. Even a few market share % correspond to a lot of people over there, we can't just ignore that.

Since D8 is still a while away maybe this can be postponed for later, but not too much, I, at least, will get to refactoring core JS pretty soon I'll need to know how we handle this.

Problem/Motivation

This doesn't directly fall under the purview of any particular official initiative, but I'm tagging it for them anyway because it's relevant.

We all know the installer is the red headed stepchild of Drupal, even among red headed stepchildren. There are many reasons for that. Mostly it boils down to:

1) Most of Drupal expects to be running in an installed state, and so we have to hack around that for a special case.
2) Core only supports database-based sessions, so we cannot use a session to store data. That means all sorts of grotesque contortions to pass data along a multi-step form without using any sort of data storage mechanism.
3) It was implemented before any good client-side storage mechanisms existed.
4) Let's be honest, given all of the above, no one has really tried to make the installer a *good* system, just a *working* system. That was hard enough.

Proposed resolution

However!

1) We now have this great new kernel, router, and http library in core courtesy of Symfony.

2) That includes a new session implementation that includes a PHP-native backend, which we can use at all times, even in an uninstalled state. (See #335411: Switch to Symfony2-based session handling for where we're trying to use the new session code for core, too.)

3) That includes the ability to define "routes" (paths and controllers) without using the database.

4) All of our supported browsers for Drupal 8 support real client-side functionality, and arguably we can rely on Javascript, you know, existing.

That means... we can rewrite the installer to be its own Symfony-based micro-application. And in the process, greatly simplify and modernize the code.

The basic idea is this:

1) Implement a new kernel class specific to the installer, using all of the default Symfony components. No custom implementations necessary the way core will need.
2) Give the installer kernel a hard-coded set of routes. There's probably like a half-dozen here.
3) Implement each "step" in the installer as a separate controller at its own path, rather than chaining GET parameters out for a few miles. As a bonus, that makes it possible to actually test each step individually(!)
4) Use a PHP-native session or client-side sessionStorage or whatever to store data rather than throwing crap into the GET string.
5) Clean up a crapload of stuff along the way.
6) Profit!!1!

Note that we will almost certainly run into places where things are still ugly and cannot be made non-ugly just be working around them. That's fine. Anywhere that we find the installer cannot be done without ugliness is a clear sign that we need to refactor something. In a sense, we're using the kernel as a canary in the coal mine to help flush out the sort of refactoring and pulling-apart-of-things-that-are-wrongly-coupled we're going to have to do anyway.

And getting a much better and more maintainable installer out of it is good, too.

Remaining tasks

I have a preliminary stab at this in the kernel-installer branch of the WSCCI sandbox. It's barely started, but it starts to lay out the basic idea. Someone not named Crell needs to pick this up and run with it. :-) Who wants to be the hero of Drupal and make the installer not suck? (Contact me for access to the sandbox if you want.)

Once the installer is done, the same thing can and should be done to both cron.php and update.php. (Actually cron.php may not be necessary anymore, but definitely update.php should also become its own little micro-app.)

User interface changes

The installer's pseudo-paths should turn into real paths. Otherwise there should be no significant UI changes.

API changes

This *should* be possible to do without changing the API for install profiles, but that will be determined by implementation. (Although we may want to adjust the install profile API as well in light of the new installer in a follow-up patch.)

Who wants it???

Partially a follow-up of #1174640: Add new HTML5 FAPI element: number: We have a number element - there are more places where it should be used and legacy validation should be replaced. But there are also plain bugs (i.e. missing validation). Those are indicated with a !.

Issue / setting / variable No
validation Tests
written user_picture_file_size ! X filter_url_length ! X Image effects (dimensions, ...) image_jpeg_quality minimum_word_size (Search module) ! X Image field settings (dimensions, file size, ...)

Follow up. Now that we have #1174640: Add new HTML5 FAPI element: number it's time to use the new element type.
That is:

• Replace element_validate_integer() with '#type' => 'number'. Default step is 1, so nothing special for integers.
• Replace element_validate_integer_positive() with '#type' => 'number', '#min' => 1. Default step is 1, so nothing special for integers. Negative numbers and zero are not allowed, so the minimum is 1.

In discussing jQuery UI vs Drupal's autocomplete here #675446: Replace autocomplete.js with the jQuery UI Autocomplete plugin

On Twitter with Paul Jackson, I'm wondering if we should revise our approach to autocomplete to leverage this feature of HTML5.

http://www.w3schools.com/html5/tag_datalist.asp

This would allow the use of HTML5 + jQuery mobile for mobile and HTML5 + jQuery UI for desktop.

http://www.w3.org/TR/html5/common-input-element-attributes.html#the-auto...
#1275764: Allow FAPI usage of the autocomplete attribute
#1277282: Add support for #autocomplete to relevant Field API widgets

Follow-up from #1471382: Add IE-conditional classes to html.tpl.php.

The problem

We've dropped IE6 and IE7 support, however there is still code in core that only exists to serve IE6 and IE7.

Additionally there is discussion in #1465948: Drop IE8 support in Drupal core about dropping IE8 support. Whether we do or not, we can isolate CSS hacks into specific conditionally loaded IE8 stylesheets so it's easier to remove later.

There is also markup in core that only exists for IE8, for example .odd and .even styles. Personally I think we could drop support for those now - they can be added back by js if people need to support them in contrib quite easily.

Remaining tasks

Identify as much code as possible in core that was written to support IE8 or lower, whether documented or not. Open issues to either:
- remove it
- move it to conditional stylesheets
- properly document it as removable when we drop support for IE8 (or introduce respond.js).

Related to #1140356: Add async property to script tags.

These lines from common.inc...

<?php // Element properties that do not depend on item type.
$element = $element_defaults;
if (!empty($item['defer'])) {
   $element['#attributes']['defer'] = 'defer';
}
?>

...Are in direct conflict with this draft HTML 5 spec:

The defer and async attributes must not be specified if the src attribute is not present.

Problem / Motivation

Make the new HTML <input type="time" .../> element available as an FAPI element in core.

References

W3C: http://www.w3.org/TR/html5/states-of-the-type-attribute.html#time-state

Problem / Motivation

Make the new HTML <input type="week" .../> element available as an FAPI element in core.

References

http://www.w3.org/TR/html5/states-of-the-type-attribute.html#week-state

Problem / Motivation

Make the new HTML <input type="month" .../> element available as an FAPI element in core.

References

W3C: http://www.w3.org/TR/html5/states-of-the-type-attribute.html#month-state

Problem / Motivation

Make the new HTML <input type="datetime-local" .../> element available as an FAPI element in core.

References

W3C: http://www.w3.org/TR/html5/states-of-the-type-attribute.html#local-date-...

Problem / Motivation

Make the new HTML <input type="datetime" .../> element available as an FAPI element in core.

References

W3C: http://www.w3.org/TR/html5/states-of-the-type-attribute.html#date-and-ti...

Problem / Motivation

Make the new HTML <input type="date" .../> element available as an FAPI element in core.

References

W3C: http://www.w3.org/TR/html5/states-of-the-type-attribute.html#date-state

Within the Drupal 8's page.tpl.php, the site slogan should use an h2 instead of a paragraph tag when rendered. I have included code which makes the presentation more semantic, but I am sure the logic could be simplified some. I have included a patch and the following code modifies the existing block of code which handles slogan/site name.

          <?php if ($site_name || $site_slogan): ?>
            <?php if ($title && $site_name && $site_slogan): ?>
              <div id="site-name"><strong>
                <a href="<?php print $front_page; ?>" title="<?php print t('Home'); ?>" rel="home"><?php print $site_name; ?></a>
              </strong></div>
  <div id="site-slogan"><?php print $site_slogan; ?></div>
<?php elseif($title && $site_name): /* Use div when the content title is not empty and site name exists */ ?>
  <div id="site-name"><strong>
                <a href="<?php print $front_page; ?>" title="<?php print t('Home'); ?>" rel="home"><?php print $site_name; ?></a>
              </strong></div>
<?php elseif($title && $site_slogan): /* Use div when the content title is not empty and slogan exists */ ?>
  <div id="site-slogan"><?php print $site_slogan; ?></div>
            <?php elseif($site_slogan && $site_name): /* Use hgroup when the content title is empty and slogan and site name exists */ ?>
              <hgroup> 
    <h1 id="site-name">
                  <a href="<?php print $front_page; ?>" title="<?php print t('Home'); ?>" rel="home"><?php print $site_name; ?></a>
                </h1>
<h2 id="site-slogan"><?php print $site_slogan; ?></h2>
  </hgroup>
<?php elseif($site_slogan): /* Use h2 when the content title is empty and slogan exists */ ?>
<h2 id="site-slogan"><?php print $site_slogan; ?></h2>
            <?php endif; ?>
          <?php endif; ?> AttachmentSizeStatusTest resultOperations semantic-slogan-page.tpl_.php_.patch1.66 KBIdlePASSED: [[SimpleTest]]: [MySQL] 35,683 pass(es).View details | Re-test

It's time to do it again: bring progressbar to next level. It's a follow-up for #653620: Bring progressbar to the modern era and #902490: progress.gif doesn't tile properly.

Problem:

- Our current progressbar is hard to maintain (it needs access to original Photoshop assets) and re-style / build on top of it.
- Its blue hue is not in sync with core themes :)
- It does not use semantic markup / HTML5

Proposal:

1. Create new "backend" for progressbar. Options:

- HTML5 http://caniuse.com/#feat=progressmeter and http://www.useragentman.com/blog/2012/01/03/cross-browser-html5-progress... and http://lea.verou.me/polyfills/progress/
- jQuery UI progressbar http://jqueryui.com/demos/progressbar
- Something similar to current div/class markup, refreshed.

2. Style it using modern technologies, drop animated GIF background. Options:

- HTML5 default styling
- Emulate current design using CSS3: http://css-tricks.com/css3-progress-bars/ and http://twitter.github.com/bootstrap/components.html#progress and https://github.com/twitter/bootstrap/blob/master/less/progress-bars.less
- Combination of two above